Mobile optimizations

[splitbrain]

We already talked about it but hadn't a ticket for it.

I just scribbled down a few ideas for the general layout:

Aks questions if something is not clear.

We might also have look at what wikipedia does in their mobile view.

[selfthinker]

Why "skip to TOC"? I would rather hide the TOC completely in a mobile view!? Or if we keep it, you wouldn't need to jump there, because it would be closed by default anyway. (And we currently don't have any generic anchors inside tpl_content(), so would only be able to jump to the start of that anyway.)

What about title, tagline and breadcrumbs? I think title and tagline should definitely be at the top. (I guess you just left it out by accident or to make it easier to get the general idea across.) But I'm not sure about the breadcrumbs. As they usually enhance usability, they should probably stay in as well.

[splitbrain]

The title and tagline do not add valuable information. The title is already in the title tag. So they should not be in the mobile view. The functionality of going back to the start page is already behind the logo (which should be smaller than in the normal view of course).

You're right, we have no way to diferenciate between content and TOC currently, unless we use tpl_content(false) and tpl_toc() which might be one idea to solve that problem. Or we introduce some #toc__end id in the TOC generation.

The TOC would not be closed by default if you don't have JavaScript. If you have JavaScript, the skip links are hidden completely because TOC and Sidebar can be collapsed (and are by default).

The TOC is important in a mobile view because scrolling long pages on mobile is a pain. So the TOC provides the simplest way to navigate to the topic you're looking for.

I would drop breadcrumbs just to save space. Or move them to the very bottom.

One important thing that's missing from scribbles is search. It should probably go above the action bar.

[selfthinker]

Okay, good points regarding the importance of the TOC.
But if we have "skip to TOC", we wouldn't need "skip to content", as the whole TOC is basically full of skip links to various pieces of content. ;-) Therefore, I think it's okay if we just keep our current "skip to content" which will skip to above the TOC anyway.

[splitbrain]

Ah, good point

[selfthinker]

As you can see, I have just added my first try. I am already quite happy with it, but some things still need to follow. Although, I think it can go live like this.

Three things which could probably be done before Monday (but I won't do it until then, maybe @splitbrain?):

• sidebar expand/collapse tool
• collapse TOC by default
• back to top links

But I will make some changes to the core to improve the action dropdown this evening (mainly adding missing actions and language strings).

Another thing which needs to be done: Testing! So far, I have only tested in a resized desktop browser... :-/

[selfthinker]

Just saw that tpl_userinfo() is not visible in the mobile version currently. We need to think about where that fits best. But for now it should be okay to not be there.

[michitux]

I've just tested my site on my Android phone (Android 2.3.7, default browser, 320x480px screen). In my opinion the font of the navigation elements (e.g. in the toc) and especially the jump to content link should be larger.

Maybe we should also add some JavaScript to the jump to content link as now when you clicked on it once it doesn't work anymore as long as you are on the same page (as then you are already on the exactly same URL). Back to top links would be great of course. Furthermore the jump to content link worked at least on my phone only after the page was fully loaded, maybe a JavaScript-based solution could work earlier?

Wikipedia has a nice feature in their mobile version that all sections of the content are collapsed and you need to click on the header in order to expand it. That way you also don't need any toc. I think it might be worth a consideration to add that feature. I think hiding the sidebar by default, too, would make sense, maybe the state of the sidebar could be remembered in the settings cookie.

[michitux]

Some further notes:

• The media manager is completely unusable, the right pane is invisible, scrolling to it didn't work for me (it just doesn't move), the panes can't be resized.
• The summary input of the edit form is wider than the viewport, too (it is displayed on the same line as the "Zusammenfassung: " label) and causes ugly scrolling to the left (just the div (?) it is in) and it can't be scrolled back.
• The bottom line (last edited) is aligned to the right and at the left is some free space which causes a linebreak. Maybe that space could be removed?
• The popup media manager works slightly better, but I couldn't find any way to scroll the left pane and it doesn't increase the total height of the media manager
• I couldn't test file uploads because every opening of a file browser in order to select a file killed the browser and the selected file wasn't inserted by the browser after the reload of the page. I don't know if this was better with a regular upload form instead of the multi uploader (which is initialized). The problem here is that the memory of my phone is very limited (160 MB) so I would consider that a problem of the phone and not of DokuWiki.
• The edit form works including the toolbar (and it's floating popups, their position seems to be right of the visible area, but I could scroll to them), but the buttons are quite small.

There are also some minor size issues of the various input elements (e.g. checkboxes have too much space around them), I don't know if that can be fixed. When you zoom in (which is needed in my opinion) the search form and the tools dropdown overlap. When you zoom in, the save/preview/cancel buttons don't fit into one line anymore and then the cancel button is directly below the save button without any spacing between them, I think this is also bad. The buttons should be larger and have some spacing around them. The main textarea behaves a bit strange, too, sometimes I have the feeling it expands to the full height, then again it is small which means that sometimes the toolbar can be accessed, sometimes it can't.

[splitbrain]

I like the idea of collapsing sections and not using a TOC at all.

Something like the following (needs selector adjustments) would work:

    if(jQuery(window).width() <= 480){                                                                                  
        for(i=2; i<6; i++){                                                                                             
            jQuery('#icke__page div.level'+i).hide();                                                                   
            jQuery('#icke__page h'+i).click(function(){                                                                 
                jQuery(this).next('div').toggle();                                                                      
            });                                                                                                         
        }                                                                                                               
    } 

[splitbrain]

@michitux this first step of mobile optimization will focus on consuming/browsing only, not editing.

@selfthinker I think we should split up this ticket into its own milestone with separate tickets.

[selfthinker]

@michitux,
Good points: make font larger of certain navigational elements and trying to make jumping around the page easier (including what @splitbrain suggested with back to top links and collapsed sidebar).
Personally, I actually don't like the Wikipedia approach, i.e. making every section collapsible. I always end up expanding all the sections anyway and am annoyed that I have to do that to see the content.

As @splitbrain already pointed out, we were not even trying to make any mobile improvements for anything other than browsing pages. I did optimise at least the login/register and config admin a little bit. But for something like the media manager you'd need to spend a lot more time!

@splitbrain,
Splitting up this ticket, yes, but not in here. Every real issue should go into bugs.dokuwiki.org as soon as the template is live and all the ideas to improve the mobile editing experience should be collected on a wiki page on dokuwiki.org, maybe devel:mobile.
I'd like not to touch this repository (and its tickets) as soon as the repo is merged into the core. (Except for closing tickets when moving remaining tickets into the core bug tracker or the core wiki.)

[selfthinker]

I just pushed some more changes to support smaller screens in two different stages: first up to 768px (just make the page full width and put the sidebar on top) and then up to 480px (which includes the changes already done before, i.e. also changing the header and removing the pagetools etc).

I'd also like to adjust the max-device-width accordingly, but I don't want to do that without being able to test it. Can you please play around with that value and test in different netbooks, tablets and phones? I can imagine that you won't need the styles for smaller devices for a tablet and can use the styles for mid-sized devices... But I don't know how iPhones behave if you make that smaller!?